Add make setup: discover the machine instead of assuming it - #3

Stacked on #2 — merge that first, and GitHub will retarget this to main.

Answers the question #1 and #2 kept dodging: why is there no intake step? Every prerequisite in v0.1.0 was a hardcoded default that happened to be true on one workstation. check-env validated those assumptions rather than discovering the machine, and there was nowhere to record a per-machine answer — so each new host rediscovers its own paths by failing a build, and each fix so far has been a slightly better guess hardcoded in the same place.

scripts/setup.sh

make setup        # interactive
make setup-auto   # no prompts, best candidate for each, still smoke tested
make setup-show   # what this machine resolved

• Scans for every CUDA toolkit (/usr/local/cuda*, /opt/cuda*, $CUDA_HOME, nvcc on PATH) and every gcc/g++ pair (PATH, distro prefixes, /opt/*/bin, asdf installs, and CONCEIT_CC_SEARCH_PATH). That last one is not an escape hatch — a toolchain built from source is precisely the one PATH does not know about, which is the case that motivated this.
• Reads the gcc cap out of the chosen toolkit's own crt/host_config.h, so the constraint comes from the toolkit rather than a README that goes stale one CUDA release later.
• Compiles a real CUDA translation unit with the pair you pick. nvcc -ccbin on a three-line kernel takes three seconds and is the only evidence that a toolkit and host compiler actually agree. Everything above it is inference; when they disagree, the compile wins. A failure prints nvcc's own diagnostic and re-prompts.
• Persists to conceit.env (gitignored — it describes one machine), sourced by cuda-env.sh ahead of every default. Each line is itself a ${VAR:-default}, so precedence reads: exported by hand > this machine's intake > the guesses in cuda-env.sh.

.agents/skills/env-intake/SKILL.md

The directed workflow around the script, for what a scan cannot decide: which toolkit a machine standardizes on when several are installed, where an unpackaged toolchain lives, and whether a failed smoke test means "pick another compiler" or "this machine needs a package." It also says plainly not to reach for -allow-unsupported-compiler, which trades a five-second failure for a corrupt build hours later. Symlinked into .cursor/skills/ like build-triage.

Verification

On a box with CUDA 13.3, gcc 16 as the system default and gcc 15 alongside:

• auto mode picks gcc-15 and compiles clean
• interactively picking gcc 16 fails the smoke test with nvcc's own gcc versions later than 15 are not supported and re-prompts
• a clean shell sourcing cuda-env.sh inherits the file; a hand-exported CC still overrides it
• make check-env passes on the result
• make check passes with the CI-pinned shellcheck 0.11.0; skill frontmatter validates

Caught one bug in my own code while testing: nvidia-smi on a host with a driver/library version mismatch prints that error to stdout, in the same shape as a result, and it sailed straight into TORCH_CUDA_ARCH_LIST until the compute caps were filtered to well-formed values.